Lightning Experience offers Admins a whole new set of tools to customize your Salesforce org. But, if you aren’t careful, you’ll quickly configure yourself into a complex, webbed mess which will be hard to maintain, and harder to hand off to someone else.

I recently wrapped up a Salesforce implementation and was working on the Solution Handoff Document, and while I was putting the documentation together, I realized that we have a lot of layers for the client to consider as they take over the implementation and begin to manage their org. It dawned on me that Lightning Experience offers so many configuration options, that it can be hard to remember how it all fits together which may result in some hair loss over the course of time!

Let’s explore some of those complexities, and talk about how you can keep from losing your mind.

Lightning Record Page Assignments

Salesforce Classic offered a simple mechanism for customizing a page with Record Types and Page Layout Assignments. Page Layouts could be assigned by Profile and Record Type, and that was it. The Page Layout was driven by Profile and Record Type Assignment.

The above is still true in Lightning Experience, but we now have an additional piece of configuration called a Lightning Record Page. The Lightning Record Page essentially sits on top of the Page Layout and is used to determine how the Lightning Components are displayed to a user. Just like with Page Layouts, these Lightning Record Pages can be assigned to users so that the user experience is uniquely tailored to the person viewing the record.

There are three ways that a Lightning Record Page can be assigned to users:

• Org Default
• App Default
• App, Record Type, and Profile

Org Default assigns the Lightning Record Page to all Profiles giving all users the same page structure across the board. Keep in mind that the Page Layout may still differ by Profile based on Page Layout assignments.

App Default assigns the Lightning Record Page as the default for a specific app. So, let’s say that you have a Sales App and a Marketing App. You can create a Lightning Record Page which is more Sales focused and assign is as default to the Sales app, and create a similar but more Marketing focused Lightning Record Page for the same object, and have it defaulted for the Marketing App. This gives each type of user a more tailed user experience.

App, Record Type, and Profile assignments are quite popular with clients because it offers the most flexibility. It allows a Lightning Record Page to be assigned to a specific App, and Record Type, and Profile. So, the combinations can be quite numerous and this is where the complexity really starts to make itself known.

Let’s say that you have 4 record types on the Case object, and the org has 15 profiles and 2 custom apps. Depending on the requirements, you could have a total of 120 combinations of Lightning Record Page assignments – just for the Case object!

You can begin to see how managing Lightning Record Pages can be complex as a result. No longer do you need to check Page Layout and Record Type assignments, you need to also manage these Lightning Record Page assignments.

The best advice when managing Lightning Record Pages is to keep the pages simple, and few in count. Just because you can create 10 Lightning Record Pages for an object doesn’t mean you should. Determine what the requirements dictate, and work to accomplish the delivery of those requirements in as few Record Pages as possible.

Keep in mind that some of your critical objects (like Cases, Opportunities, or Accounts) may have a larger number of Assignments and unique combinations because they are central to the business processes. Just try to keep the assignments simple.

Personally, I try to use the Org Default as much as possible. I don’t find the App Default assignment to be much help because most clients are using a single App for all of their users, which means then that my only other option is to use the App, Record Type, and Profile option.

In addition, if you are needing a more complex deployment of Lightning Record Pages, make sure that you’re documenting somewhere what the differences are between the record pages and why you went that route.

Lightning Components

One of the beautiful parts of Lightning Experience is its modularity. The ability to build robust, functional, and user experience focused user interfaces is all possible because of Lightning Components.

Lightning Components are a part of the Lightning Record Page configuration, and offer a lot of flexibility. But with this flexibility comes complexity.

Not only can each Lightning Record Page have a different arrangement of Components, but the Components themselves have their own properties that can be managed as well which can be found by clicking on a component in the page builder.

In the screenshot above, I’ve selected the Highlights Panel and you can see that in the right-hand properties panel, I have some options to further configure the component. For this specific component I can show it collapsed (which would not display the additional fields in the highlights panel) and I can change the number of Action Buttons that display.

You can see how (Lightning Record Pages) x (Lightning Component Properties) x (Profiles) x (Apps) begins to create quite a web of Admin overhead.

Dependent Components on Lightning Record Pages

While Record Page Assignments can be cumbersome in themselves, individual Lightning Components on those Lightning Record Pages can be made visible based on specified conditions. This functionality is HUGE and offers a more dynamic way to engage with the record.

Let’s say that a record should be submitted for approval, but only under certain circumstances. Users won’t always remember when the record needs to be approved, so you could add a Rich Text component with a reminder to submit the record for approval, and have that component display only when the record requires approval.

Components can also be visible based on the user’s profile, role, or based on a specific permission assigned to the user.

While all of this is great (and I do use the functionality because it’s tremendously helpful), you can see already that this is another “failure point” that needs to be managed.

If configuration changes (like a picklist value or field name) or user permissions are modified, you now need to consider if any changes are required on the components that have visibility conditions and make the appropriate updates.

Don’t shy away from using this functionality, but like with everything else, determine first if there is a more scalable way to accomplish the goal. If not, then determine how to make the component visibility criteria scalable. Ideally, you shouldn’t have to touch or modify the criteria every time there is a change.

Keep the number of components that have visibility conditions to a minimum so that there is less overhead to maintain.

Don’t forget to document! You need some record in a document somewhere of what components are dependent and under what conditions. It will make it much simpler to review a document with these permissions than to click into multiple Lightning Record Pages to validate which components have dependancies and if they need to be changed or modified.

Path

Path is a fantastic way to add a visual process to any object – including Accounts! However, Path has its own section in Salesforce Setup for creating and managing Paths for your org.

While the Lightning Record Page allows you to determine where Path should reside on the page, Path itself is driven based on your configuration and works. It’s record type driven, and is typically created based off of a Status or similar type field.

As you begin to build a Path for every object and potentially every record type, you’ll soon find that managing changes isn’t necessarily challenging, but is additional overhead. You could easily end up with 20, 30, or 40 different Paths depending on record type counts and how extensivley you use them.

The saving grace is that Path does not change that frequency once it’s been set.

Lightning Apps

Just like with Salesforce Classic, Administrators can create custom Applications which can be assigned to different groups of users. The Apps are customized to serve that specific user population by providing them access to the objects they use every day, as well as potentially customized views, Lightning Record Pages, and more.

We covered the complexity of the Lightning Record Pages in the first section (one of the complexities being assignments by App or App and Profile) but Lightning Apps now have a more robust set of settings that can be enabled and may require management.

While you have your standard App settings like Profile Assignments and Navigation items, there are new settings in Lightning including Utility Bar navigation (which displays at the bottom of the page) and options including Form Factor (is the app going to be supported on desktop, mobile, or both).

While creating the app and managing it isn’t terribly difficult (or different from Classic), managing the apps are so infrequent that you can easily forget where to make a change to the App settings. In addition, I always get confused on if I choose Lightning App Builder in Setup Navigation or App Manager to make the changes! For the record, you use the App Manager to manage apps! 😉

Managing These Complexities

As I’ve mentioned already – don’t shy away from using any of this functionality, but do realize that there is more Administrative overhead you’ll need to consider when it comes to managing the org. Keep things simple. Also, don’t forget to document.

Documentation, however formal you want to make it, will help you recall how the system was configured, and it will also help the next Admin get up to speed quick.

If you’re looking for a good documentation tool, check out these two apps. I haven’t used either (and they are not sponsoring this post) but I have seen both in action, and I think they are really amazing applications.

• Spekit (https://spekit.co/)
• Elements (https://elements.cloud/)

Both tools allow you to document within the app, and within context. Depending on the app, you can also see documentation within the app itself. They are also great for end user training (specifically Spekit).

What other Lightning Experience complexities have you run into? Leave a comment below or find me on Twitter!